Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PG-1056 xmin and xmax correctness #292

Merged
merged 5 commits into from
Oct 8, 2024
Merged

PG-1056 xmin and xmax correctness #292

merged 5 commits into from
Oct 8, 2024

Conversation

artemgavrilov
Copy link
Collaborator

@artemgavrilov artemgavrilov commented Sep 23, 2024

Copy link

github-actions bot commented Sep 23, 2024

Performance test results:
Normal queries: 9397
TDE queries: 8915
Percentage: 94%

@artemgavrilov artemgavrilov changed the title PG-1056 Add failing test PG-1056 xmin and xmax correctness Sep 24, 2024
@dAdAbird dAdAbird marked this pull request as ready for review September 27, 2024 11:18
@dAdAbird dAdAbird requested a review from dutow September 27, 2024 11:18
@dAdAbird
Copy link
Member

@dutow see my commit's message.

  1. Here it says:
    "To be safe, it also disables the get tuple function, forcing the core code to use copy instead when needed."
    But I don't see why would we need this. If get tuple function is NULL it calls backend's heap_copytuple() (not our slot_copytuple()) which results in extra palloc instead of just passing the pointer. Besides, see my comments.

Am I missing something?

  1. As far as I can tell my commit should not compromise optimizations of Performance / memory usage fix: do not allocate memory in pg_tde_slot #265. What do you think?

If `get_heap_tuple` is NULL, the core uses `copy_heap_tuple` instead. The former returns a pointer to a tuple in the slot and the latter makes a copy of such a tuple. For UPDATE SET, the core uses the slot for INSERT and later for RETURNING processing. If we copy the tuple the next happens:
1. The core creates a slot with the generic tuple.
2. It passed to `pg_tdeam_tuple_update()` and it gets a copy of the tuple here [https://github.com/Percona-Lab/pg_tde/blob/6d4f7e5b7bd2507ce65deb315ea8d5647f474cf9/src17/access/pg_tdeam_handler.c#L336].
3. This generic tuple is filled with the proper data and used for the update here [https://github.com/Percona-Lab/pg_tde/blob/6d4f7e5b7bd2507ce65deb315ea8d5647f474cf9/src17/access/pg_tdeam_handler.c#L343].
4. Later on, RETURNING processing uses the slot's tuple but is still a  generic unmodified one because of the copy.
5. That results in wrong RETURNING data.

To avoid this, we should return a pointer to the slot's tuple instead of copying it.

Fixes PG-1056
@dutow
Copy link
Collaborator

dutow commented Sep 27, 2024

@dAdAbird my concern was that if we only get the tuple and do not copy it, we might find issues because we reuse the same memory again for the next tuple. If I understand the API correctly, this shouldn't happen, but it seemed safer to disable get, and force copy. Looks like I was wrong about that.

@artemgavrilov
Copy link
Collaborator Author

Before merge I think we should remove test it this PR because it's isolated case from PG regression suite. Not sure that we need it in tde repo. What do you think?

@artemgavrilov artemgavrilov merged commit 3e4c889 into main Oct 8, 2024
14 checks passed
@artemgavrilov artemgavrilov deleted the PG-1056-xmin-xmax branch October 8, 2024 16:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants